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ABSTRACT 

This  thesis  places  the  Information  Resource  Management 
Architecture  of  the  U.S.  Coast  Guard  in  the  'contagious 
growth'  stage  of  Nolan's  model  of  organizational  computer 
growth.  Control  is  the  next  stage  predicted  by  the  model. 
The  financial  accounting  basis  of  EDP  chargeback  and  control 
systems  is  examined  as  a  precursor  to  developing  five 
management  control  requirements  of  the  IRM  architecture. 
These  include  (1)  aggregate  financial  accounting  for  infor- 
mation services,  (2)  an  auditable  user  access/authorization 
scheme,  (3)  a  user -ori ented  chargeback  system,  (4)  pricing 
to  establish  an  information  marketplace,  and  (5)  an  informa- 
tion decision  tool  to  assist  in  user  tradeoff  decisions 
between  information  services.  Finally,  an  integrated  system 
to  satisfy  these  requirements  at  the  Coast  Guard  District 
Office  level  of  the  IRM  architecture  is  described,  based  on 
a  Local  Area  Network  system. 
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I.  THE  COAST  GUARD  IRM  ARCHITECTURE 

A.  INFORMATION  SYSTEM  PROJECTS 

In  the  early  1970's,  the  U.S.  Coast  Guard  began  automa- 
ting and  integrating  the  administrative  and  communications 
systems  which  constitute  its  servicewide  Information  System. 
A  number  of  major  Information  System  Projects  were 
identified,  each  specifying  a  single  functional  system, 
usually  vertically  integrated  from  the  data-entry  field  unit 
through  to  the  Program  Manager  level  at  Coast  Guard 
Headquarters.  Examples  include  the  Operational  Information 
System  project  (OPINS),  the  Personnel  Management  Information 
System  (PMIS),  the  Marine  Safety  Information  System  (MSIS) , 
and  the  Standardized  Aids  to  Navigation  System  (SANDS). 
Other  projects  became  necessary  to  support  these  Information 
Systems;  the  Standard  Terminal  Project  competitively  bid  a 
requirements  contract  for  procurement  of  up  to  3900 
intelligent  communications  and  data  entry  terminals,  and  the 
Semi -Automated  Message  Processing  Project  (SAMPS)  began 
computerizing  manpower  intensive  relay  points  in  the  record 
communications   network. 

B.  THE    OFFICE    OF    T 

The  Paperwork  Reduction  Act  of  1980  mandated  a  central 
point  of    information   management    in    each    agency.       In    1981  , 


responsibility  for  the  various  Information  Projects,  and 
for  Information  Resource  Management  Coast  Guard-wide  was 
vested  in  a  newly  formed  Office  of  Command,  Control  and 
Communications  (C^ ) ,  synthesized  from  the  former  Financial 
Information  Systems,  Electronic/Electrical  Engineering,  and 
Telecommunications  Management  Divisions  at  Coast  Guard 
Headquarters.  Its  staff  symbol,  ( Commandant )G-T ,  became 
widespread  verbal  shorthand  and  the  "Office  of  T"  was  born. 

C.   THE  U.S.  COAST  GUARD  INFORMATION  RESOURCE  MANAGEMENT 
ARCHITECTURE 

An  overall  schema  was  needed,  to  guide  the  integration 
and  coordination  of  the  various  separate  information  systems 
and  the  supporting  projects  into  a  servicewide  Coast  Guard 
Information  System.  The  Office  of  T  developed  and  published 
the  Coast  Guard  Information  Resource  Management  Architecture 
illustrated  in  Figure  1.  The  two  primary  policy  documents 
supporting  and  implementing  this  architecture  are  the 
(DRAFT)  Command,  Control  and  Communications  (C3)  Plan  [Ref. 
1],  and  the  Command,  Control  and  Communications  (C3)  Support 
Program  Plan,  1982-1992,  [Ref.  2]. 

1  .   Overview  and  Critical  Success  Factors 

The  best  overview  and  explanation  of  the  Information 
Resource  Management  (IRM)  Architecture  is  in  the  C3  Plan 
itself : 
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U.S.  Coast  Guard  Information 
Resources  Management  Architecture 


TIME  SHARING  SVCS 


MAJOt  1*0*1  FACJUTT 

Minicomputer 


CG  HQ 


DIMS 


INFO«MAT>0« 
CSNTfB 


DOT 
C*m*f 


OTHER 
A6CNOES 


-JZ^pp^yl^ 


IHtnOAtO  INFORMATION 
MANGT  SYSTEM 


RAMS 

«UOCCT  (A-ll) 
HUMAN  RESOURCES 
A^niCATtONS 
__  SOFTWARE  PACXAGES 

5^'  "^  SUF»ORT  (LMS/SMEF) 

•OATS 


Figure    1  . 


U.S.  Coast  Guard  Information  Resources 
Management  Architecture 


"Information    Architecture    Plan. 

The  first  step  in  effective  Information  Resource 
Management  is  to  develop  the  Information  Architecture 
Plan.  This  is  similar  to  a  business  plan  in  a  commercial 
firm.  The  information  needs  and  activities  of  the  various 
parts  of  the  organization  (emphasis  added)  are  collected 
and  analyzed  to  determine  the  manner  in  which  data  must  be 
organized  to  support  them.  This  leads  to  development  of  a 
logical  model  which  describes  the  arrangement  and  activi- 
ties of  the  organization.  This  logical  model  has  been 
found  to  be  quite  stable  unless  the  fundamental  character 
of  the  organization  is  altered  or  its  missions  change 
radically  in  a  short  time.  Because  the  logical  model  is 
stable,  evolutionary  changes  can  be  accommodated.."  [Ref. 
1  :    p.    32]  . 

The  added  emphasis  underscores  the  fact  that  unless 
a  part  of  the  organization  articulates  an  information  need 
or  activity,  the  Plan  cannot  address  it.  Needs  of  the 
system  overall,  "global"  needs  (like  a  need  for  management 
control)  will  not  enter  the  Architecture  without  a  sponsor, 
since  they  are  not  the  assigned  task  of  any  specific 
organizational    element. 

The  Coast  Guard  has  identified  four  Critical  Success 
Factors  for  developing  the  Information  Resources  Management 
Architecture: 

1 .  Intelligent  Terminals--to  provide  a  vehicle  for  local 
processing,  source  data  entry,  and  access  to  the  net- 
work( s ) , 

2.  Data    Base    Technology--to    control    the    data    resource, 

3.  The  Communications  Network--to  provide  connectivity, 
and 

4.  Integration  —  of    the    parts    into    a    whole. 
[Ref.    3:    p.    STSP3  ] 
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The    emphasis    on    database    technology    was    not    intended    to 

allow    the    creation   of    many    parallel    vertical    information 

systems : 

"The  IRM  architecture  and  other  policies  of  the  (Office  of 
T)  program  discourages  the  proliferation  of  field-unit 
terminals  connected  independently  to  s ingle- program 
central  data  bases.  This  would  be  an  electronic  version  of 
our  present  uncoordinated,  overlapping,  manual  information 
system."      [Ref.    1:     pp.    4-7] 

The     databases     shown,      at     Headquarters,      in     the     District 

Offices,    and    at    major    shore    facilities,    are    to    be    shared, 

multi-purpose    databases. 

The  number  of  mini-computers  shown,  coupled  with  the 
identification  of  intelligent  terminals  as  a  Critical 
Success  Factor,  mean  that  this  is  a  'distributed'  system. 
Computing  power  is  placed  as  close  as  possible  to  the  people 
who  need  to  use  it.  This  contrasts  with  a  centralized  system 
where  all  computing  is  done  at  one  usually  large  central 
computer  and  user  terminals  are  capable  only  of  data  entry 
and    routine    inquiries. 

2.       Classes    of    Information    Serviced 

The  CJ  Support  Plan  addresses  the  three  classes  of 
information  which  the  IRM  Architecture  will  have  to  service: 
transactional,  hierarchical,  and  local.  Figure  2  illus- 
trates   the    flow    of   hierarchical    information: 

"This  figure  shows  hierarchical  information  flowing  from 
the  smallest  unit,  to  the  top  of  the  Coast  Guard,  and 
ultimately  beyond  to  both  Congressional  and  Executive 
recipients.  While  all  three  types  of  information  have 
gray  areas  of  overlap,  the  essential  features  of 
hierarchical    are    aggregation,     and    use    by    management    over 
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time  periods  of  weeks  to  years.  These  two  features  mean 
that  the  timeliness  of  the  information  is  not  critical, 
and  the  precision  and  detail  of  the  aggregated  information 
decreases  as  the  hierarchical  level  increases.  Hierarchi- 
cal information  supports  the  management  control  and 
strategic  control  functions  of  the  organization.  [Ref.  2: 
p.  4-2  ] 

Hierarchical  Information 


Higher  Gov't 


Coast  Guard  District 


Units 


Time  Not  Critical 

Data:  Complex  Structure 

Aggregated  £r  Summarized 

Uaa:     Management  Aliocation.  Planning.  Control 
Traditionally:  Papar  Systems 

Figure    2.       Flow   of    Hierarchical    Information 


Transactional    information    flow    is    shown    in    Figure    3    and 

defined   as    follows: 

"This  figure  illustrates  transactional  information, 
based  upon  data  groupings  which  flow  intact  from  point-to- 
point  in  the  organization  and  usually  cause  or  support 
rapid  activity.  In  contrast  to  hierarchical  information 
the    precision   of    transactional    information    is   constant    and 
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transactions  are  not  usually  aggregated.  This  information 
type  is  often  found  in  our  present  record  communications 
and  feeds  the  operational  control  function!  operating  the 
organization  day-in  and  day-out).  A  "message  MILSTRIP"  is 
a  perfect  example.  Transaction  information  often  has  a 
complex  input  to  hierarchical  and  this  input  (and  often 
its  duplication)  is  a  significant  problem/cost  to  the 
Coast   Guard."    [Ref.    2:     p.    4-2] 

(The     message     MILSTRIP     mentioned     is    a     telexed     supply 

requisition.)    Local    information    is    defined    as    any    and    all 

information    that    an    individual    or    organizational    element 

chooses    to    use    and     keep     when     it     is     not     institutionally 

required    to   do    so. 


Transaction  Information 


Operational 

Computer 

Center 


HQ 
Rag  Plot 
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Support 
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Wire- 
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Traditional:  CG  Record  (message)  Communications 


Figure  3.   Flow  of  Transactional  Information 
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3 .   The  Role  of  the  District  Office 

Central  to  all  three  of  the  figures  depicting 
information  flow  in  the  Coast  Guard  has  been  the  Coast  Guard 
District  Office.  Situated  between  the  strategic  level  of 
Coast  Guard  Headquarters  and  the  operational  level  of  the 
field  units,  the  District  Headquarters  operates  at  the  level 
of  management  control.  Every  major  Headquarters  Office 
and/or  Program  Manager  connects  to  a  corresponding  District 
Division  or  Branch.  Districts  are  responsible  for  managing 
Coast  Guard  resources  within  a  given  geographic  area  (i.e. 
Fifth  District  =  Maryland,  Virginia,  N.  Carolina).  The 
District  Commander  (a  two-star  Admiral)  as  the  principal 
agent  and  representative  of  the  Commandant,  is  responsible 
for  the  administration  and  general  direction  of  district 
units  under  his  command.  Within  his  District,  he  is 
responsible  for  carrying  out  the  functions  and  duties  of  the 
Coast  Guard  and  for  assuring  that  these  duties  are  performed 
efficiently,  safely  and  economically.  Districts  produce  the 
majority  of  transactional  information.  [Ref.  2:  pp.  1-10] 
Table  I  shows  the  names  and  locations  of  the  twelve  District 
Offices . 

The  District  Commander's  responsibility  for  local 
control  of  Coast  Guard  resources  extends  to  information 
resources,  too.  In  1981,  three  officer  billets  (One  Comman- 
ded 0-5),  one  Lieutenant (0-3 )  and  one  Warrant  Officer(CWO- 
4))    were    added    to    the    staffs    of    each    of    the    twelve    District 
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Offices  to  form  the  nucleus  of  an  IRM  staff.  Combined  with 
the  existing  telecommunications  organization,  they  are  meant 
to  evolve  into  the  pr ovider s / super vi sors  of  all  the 
information  services  shown  in  the  "CG  District'"  box  within 
Figure  1.  This  District  IRM  staff  will  operate  the  Local 
Area  Network  and  the  District  Mi ni -Computer ,  maintain  the 
District  database  and  provide  the  Information  Center 
services    specified    in    the    IRM    Architecture. 


Table  I.   U.S.  Coast  Guard  District  Office  Locations 


District 


First  District 
Second  District 
Third  District 
Fifth  District 
Seventh  District 
Eighth  District 
Ninth  District 
Eleventh  District 
Twelfth  District 
Thirteenth  District 
Fourteenth  District 
Seventeenth  District 


District  Headquarters 
Location 

Boston,  MA 
St  Louis,  MO 
New  York,  NY 
Portsmouth,  VA 
Miami,  FL 
New  Orleans,  LA 
Cleveland,  OH 
Long  Beach,  CA 
San  Francisco, CA 
Seattle,  WA 
Honolulu,  HI 
Juneau,  AK 


D.   THE  DISTRICT  LOCAL  NETWORK 

While  the  IRM  Architecture  and  its  support  plans  provide 

for  and  define  a  local  network  capability  for  each  District, 

it  is  not  a  critical  nor  a  high-priority  project.  The  C 

Plan  defines  the  Local  Network  as  follows: 

"Within  the  district  office  building  and  immediate 
surroundings,  the  local  net  provides  for  information 
distribution  through  interconnected  clusters  of  Standard 
Terminals  or  other  existing  office  information  systems. 
Primary  objectives  are  shared  electronic  files,  electronic 
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mail,  word  processing  and  shared  information  processing." 
[Ref .   1  :    pp.    1  -10 ] 

The  implementing  Support  Plan  notes  that  the  multi-user 
capabilities  of  the  Standard  Terminal  resemble  network 
connectivity,  and  that  clusters  of  Standard  Terminals  could 
be  interconnected  in  a  'message  mode'.  However,  this  inter- 
connection and  more  advanced  techniques  like  wideband 
channel  local  area  networks  "will  not  be  pursued  for  general 
Coast  Guard  use  through  the  mid-80's,  although  R&D  evalua- 
tion would  certainly  be  in  order"  [Ref.  2:  pp.  4-10].  The 
reasons  are  given  in  a  section  titled  "Future  Technology 
Impact    on    the    Architecture": 

"A  number  of  promising  technologi  es ..  .have  been  excluded 
from  this  version  of  the  support  plan.  The  basic  reason 
has  been  one  of  practical  choice;  the  limited  resources 
available  to  the  program  and  the  need  for  evolutionary 
growth  dictate  that  higher  risk  or  non-integrable  ventures 
be    excluded... 

Local    Networks 

Mixed  voice/data/video  has  potential  payoff,  but  lack 
of  control  of  most  telephone  installations  makes  this 
difficult  to  exploit.  Some  use  of  this  later  in  the 
decade   will    no   doubt    occur."    [Ref.    2:    pp.    4-20]. 

Each    District    is    responsible    for   the    design,    acquisition, 

operation  and   maintenance   of    information    (voice    and   data) 

networks    within    the    geographic    boundaries     of    the    district. 

[Ref.    2:    p.    8-2].    The    local    net    is    not    regarded    as    a    piece 

of   the    IRM   Architecture    with   systemwide    impact. 
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E.       SUMMARY 

We  have  given  a  brief  overview  of  the  Coast  Guard's 
Information  Resource  Management  Architecture,  and 
established  the  central  role  of  the  Coast  Guard  District 
Office  within  that  architecture.  The  present  status  of 
local  networks  for  the  district  offices  was  examined;  that 
"back  burner"  status  is  consistent  with  the  C°  Plan's 
perception   of    local    nets    as    non-vital    local    utilities. 

The  Coast  Guard  is  still  in  the  process  of  buying  the 
equipment  for  the  architecture,  and  at  a  rapid  rate.  That 
rate  of  growth  is  examined  in  the  next  chapter  as  an 
indicator  that  the  Coast  Guard  will  soon  need  to  impose 
management  controls  on  its  servicewide  information  system. 
Later  we  will  discuss  the  type  of  management  controls  best 
suited  to  an  i nf orm a t i on- pr oce s s ing  system,  and  the 
advantages  of  prototyped  development  of  those  controls.  A 
standard  District  Office  Local  Area  Network,  coupled  with  an 
auditable  user  authentication  and  access  system,  will  be 
suggested  as  a  mechanism  crucial  to  adding  management 
controls    to    the    IRM    Architecture. 
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II.       COMPUTER    GROWTH    IN    THE    COAST    GUARD 

A.       THE    NOLAN    MODEL 

One  widely-accepted  framework  for  understanding  and 
evaluating  data  processing  (DP)  within  organizations  is 
Nolan's  six-stage  model  for  the  introduction  and  growth  of 
the  data  processing  function  within  organizations  [Ref.  4: 
pp.  76-89].  Figure  4  illustrates  the  six  stages  and  their 
characteristics  within  each  of  four  "growth  processes".  The 
climbing  dotted  line  represents  the  level  of  expenditures  in 
the    total    DP    budget    for    the    organization. 

This  model  is  a  refinement  of  Nolan's  earlier  (1974) 
four-stage  model  based  on  the  S-shaped  curve  described  by- 
most  developing  DP  budgets  [Ref.  5:  p.  77].  The  "transition 
point"  of  the  later  (1  976)  model,  shown  in  Figure  4  is  the 
point  at  which  a  second  S-shaped  curve  takes  off.  This 
occurs  when  the  introduction  of  database  technology  causes 
renewed  rapid  growth  of  the  DP  budget.  This  later  model 
assumes  that  initial  applications  do  not  employ  database 
technology,  and  part  of  the  increased  expense  after  the 
transition  point  is  for  retrofitting  that  technology.  This 
assumption  may  limit  the  expense  curve's  direct 
applicability  to  the  Coast  Guard  IRM  Architecture,  given  the 
C  Plan's  stated  emphasis  on  widespread  use  of  database 
technology    from     the    beginning     in     all    applications.      The 
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stages  and  general  characteristics  of  the  six-stage  model, 
however,  have  been  validated  against  experience  with  more 
than  forty  large  corporations  and  should  still  apply  to 
Coast    Guard    computerization    [Ref.    4:    p.    116]. 
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Figure  4.   The  Nolan  Model  of  Organizational  Computer  Growth 

The  process   for  placing  a   corporation's  data   processing 
within    a    particular    growth    stage    involves    two    levels    of 
benchmarks: 
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"The  first  step  is  to  analyze  the  company's  DP  expenditure 
curve  by  observing  its  shape  and  comparing  its  annual 
growth  rate  with  the  company's  sales.  A  sustained  growth 
rate  greater  than  sales  indicates  either  a  stage  2  or  4 
environment.  If  data  base  technology  has  been  introduced 
and  from  15%  to  40%  of  the  company's  computer-based 
applications  are  operating  using  such  technology,  then  the 
company  is  most  likely  experiencing  stage  4."  [Ref.  4: 
p. 121  ] 

The      second      step      involves      evaluating      the      company's 

application    portfolio    against    the    investment    benchmarks 

shown     in     Table     II.         "For      instance,       80%     support     of 

operational     systems,      20%     support    of     management    control 

systems,     and    just    a    faint    trace    of    support    for    strategic 

planning    systems    would    show    the    organization    to    be    at    stage 

3."     [Ref.    4:    p.     124]. 

TABLE  II.   Applications  Portfolio  Investment  Benchmarks 

Strategic       iManagement     Operational 

planning         control         systems 
Stage  systems  systems 

1  0  0  100% 

2  < 1  %  15%  85% 

3  <1%  20%  80% 

4  5%  30%  65% 

5  10%  35%  55% 

6  15%  40%  45% 

B.   BETWEEN  CONTAGION  AND  CONTROL 

Trying  to  place  the  present  growth  stage  of  the  Coast 
Guard  IRM  architecture  is  difficult:,  because  there  are  no 
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accurate  total  IRM  budgets  prior  to  the  establishment  of  the 
Office  of  C3.  Many  of  the  operational  costs  of  the  Coast 
Guard-owned  record  telecommunication  system  (for  example, 
salaries)  are  still  disguised  as  overhead  expenses.  Many 
powerful  computers  (up  to  and  including  mini-computers)  have 
been  bought  for  word  processing,  and  don't  show  up  in  the 
budgets    of    the   comptroller-based   DP   departments. 

A  rough  approximation  can  be  made  by  simply  counting  all 
computers,  and  assuming  that  in  the  early  stages  of  growth 
expenses  are  linearly  related  to  the  number  of  available 
processing  units.  The  graph  in  Figure  5  shows  the  growth  in 
Coast  Guard  ADP  equipment  during  the  last  six  years,  based 
on  the  Coast  Guard  ADP  Equipment  Inventory.  This  inventory, 
which  GSA  (the  General  Services  Administration)  requires 
every  agency  to  maintain,  represents  a  current  census  of  any 
and  all  equipment  including  word  processors,  which  performs 
or  supports  directly  Automated  Data  Processing.  The  second 
curve  in  the  figure  shows  only  those  units  reported  as 
containing  a  Central  Processing  Unit,  i.e.  a  microprocessor; 
these  are  the  actual  'computers'  in  the  Coast  Guard 
inventory,  and  they  show  the  same  rate  of  growth  as  the 
total  hardware  curve.  Only  40%  of  the  Districts  had 
completed  reporting  their  FY  83  figures  at  the  time  these 
statistics  were  compiled,  but  the  figures  as  shown  are 
characteristic  of  the  Coast  Guard  in  general.  [Ref.  6]  The 
fallof.f     shown     in    the    first    curve    may    be     a     result     of 
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incomplete    reporting    rather    than     the    end    of    a    hardware 
growth    trend. 


USCG  ADP  EQUIPMENT  GROWTH 


1976      1877       1978       1979       1980       1981 
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Figure  5.   Coast  Guard  ADP  Equipment  Growth 

Comparing  Figure  5  with  Nolan's  DP  expense  curve  in 
Figure  4  places  Coast  Guard  computer  growth  in  Stage  2,  the 
rapid  expansion  phase  labelled  'contagion'.  This  assumes 
that  the  Coast  Guard's  total  computer  expenditures  shows  the 
same  rapid  growth  illustrated  for  both  total  equipment  and 
for    CPU-equipped   units.    Since    software    is    not   reported   in 
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the    ADP    Equipment    inventory,     the    actual    budget    probably 
shows    a    higher    growth    rate    than    illustrated. 

The  second  step  in  the  placement  method  is  a  look  at  the 
organization's     applications     portfolio.        Table     III     is     a 

listing    of     Major    Information    Projects    of     the    Office    of 

3 
Command,     Control    and    Communications,     taken    from    the    C 

Support    Program    Plan    [Ref.    2:     p.    10-1].    Each    project    has 

been  categorized    by    the  organizational    level    it    primarily 

affects.    Eleven    of    these    fourteen    initial    computer    projects 

benefit    or     improve    operations    directly.    Three    of     the 

fourteen    improve    or   support   management   control.    According    to 

Nolan's    investment    benchmarks    in   Table    II,     these    figures 

place    the    applications    portfolio    in    stage    3,     the    control 

stage.         The      current      state      of      the      Coast      Guard      IRM 

architecture    is    therefore    between    contagion    and    control. 

The    rapid   growth    in    stage    2    starts    with    the    spectacular 

successes    of    the     initial    computerization    efforts    during 

stage     1.     The    excess     computer     capacity     usually    acquired 

during    the    first    phase,    coupled   with    the    lure    of    broader    and 

more    advanced    applications,      triggers    a    period    of     rapid 

expansion.     Stage    2    represents    a    steady    and    steep    rise    in 

expenditures   for  hardware,    software  and  personnel.   It   is    a 

period    of     contagious,     unplanned    growth    characterized    by 

growing    responsibilities     for    the    EDP    director,     a     loose 

(usually   decentralized)    organization   of    the  EDP    facility, 
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and  few  explicit  means  of  setting  project  priorities  or 
crystallizing  plans. 

TABLE  III.   List  of  Major  Office  of  C3  IRM  Projects 

MAJOR  PROJECT  CATEGORY 

Marine  Safety  Information  System       Operational 

Joint  Uniform  Military  Pay  System     Operational 

Telecommunications  Study  -  Combine     Operational 
Computer  and  Record  Comms 

Office  Automation  Operational 

Command  Centers  Operational 

District  Minicomputers  Operational 

Shipboard  Assisted  Maintenance 

Planning  (SCAMP)  Operational 

Yard/Supply  Center  Inventory  Control 

Point  Acquisition  Operational 

G-T  Office  Budget  System  Management  Control 

Coast  Guard  Standard  Accounting 

System  Operational 

User  Responsibility ( Chargeback)        Management  Control 

Data  Management  Management  Control 

Cobol  Conversion  Operational 

Operations  Computer  Center  Operational 

This  stage  often  ends  in  crisis  when  top  management 

becomes  aware  of  the  explosive  growth  of  the  activity  and 

its  budget,  and  decides  to  rationalize  and  coordinate  the 

entire  organization's  EDP  effort.   The  dynamic  force  of 

expansion  makes  this  a  fairly  difficult  thing  to  do, 
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however,  and  the  growth  seems  to  be  continuing  unabated.  Top 
management  frequently  concludes  that  the  only  way  to  get 
control  of  the  resource  is  through  drastic  measures,  even  if 
this  means  replacing  many  systems  analysts  and  other 
valuable  technical  people  who  will  choose  to  leave  rather 
than  work  under  the  stringent  controls  that  are  imposed 
during  the  stage.  Firing  the  old  EDP  manager  is  by  no  means 
an    unusual    step. 

Often  what  was  a  decentralized  function  and  facility  is 
rather  suddenly  centralized  for  better  control.  Often 
informal  planning  suddenly  gives  way  to  formal  planning, 
perhaps  arbitrarily.  This  stage  frequently  includes  the 
first  formalization  of  management  reporting  systems  for 
computer  operation,  a  new  chargeback  system,  and  the 
establishment  of  elaborate  and  cumbrous  quality-control 
measures.  In  short,  action  taken  to  deal  with  the  crisis 
often  goes  beyond  what  is  needed,  and  the  pendulum  may  swing 
too  far. 

Based  on  his  studies  of  corporations  weathering  these 
computer  transition  stages,  Nolan  indicates  that  for  the 
most  part,  the  problems  that  arise  toward  the  end  of  Stage  2 
can  be  greatly  alleviated  by  introducing  right  at  the  start 
of  Stage  2  the  techniques  that  companies  ordinarily  use  in 
Stage   3."    [Ref.    5:    pp.    79-83] 

These  Stage  3  controls  are  shown  in  Table  IV  as  they 
were     presented     in     the     earlier     four-stage     model.        Also 
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significant  in  this  figure  are  the  Stage  4  controls, 
specifically  the  data  base  policies  and  standards  and  the 
focus  on  computer  services  pricing  for  effective  use.  Later 
we  will  see  that  these  Stage  4  controls  are  the  type  which 
the  C  Plan  would  like  to  implement  directly.  For  now  the 
major  points  are  that  the  architecture  is  approaching  the 
control  stage,  and  the  early  introduction  of  controls  can 
greatly  ease  the  crisis  nature  of  the  transition  to  Stage  3. 
In  the  next  chapter,  we  will  examine  the  concept  of 
control  generally,  and  the  types  of  controls  available  for 
information  systems.  Some  specific  recommendations  will  be 
made  for  management  controls  consistent  with  the  Coast  Guard 
IRM    Architecture. 
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III.       MANAGEMENT    CONTROL    OF    COMPUTERS 


A.       CONTROL    IN    GENERAL 

Management  control  is  a  cycle  that  includes  the  three 
stages  of  goal  setting,  performance  evaluation,  and  feed- 
back. These  three  stages  of  control  are  illustrated  in 
Figure  6.  (1.)  Goal  setting  involves  planning,  and 
establishing  the  goals  required  for  desired  performance 
levels.  Measuring  and  monitoring  functions  record  actual 
performance.  (2.)  Performance  evaluation  compares 
performance  reports  with  goals.  (3.)  Feedback  information  is 
designed  to  make  corrections  in  either  goals  or  work 
activities    to    bring    them    into   alignment.     [Ref.    7:    p.    310] 


1 .  Goals 
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Figure  6.    Management  Control  Stages 
This  cycle  forms  the  heart  of  management  control  systems  in 
most  businesses,  with  the  department  or  division  budget 
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quantifying  most  of  the  goals,  and  the  quarterly  financial 
statement  providing  the  performance  information  to  be 
evaluated  against  the  budget's  projections. 

B.   CONTROL  AND  CHARGEBACK  UNDER  CENTRALIZED  EDP 

Although  the  expense  and  the  technical  complexity  of 
computers  has  sometimes  obscured  the  point,  this  general 
model  of  management  control  can  be  applied  to  control  an 
Electronic  Data  Processing  department  as  directly  and  as 
well  as  any  other  department.  Top  management  has  two  main 
concerns    in    controlling    the    EDP   department: 

1.  Are     we    spending    too     much,     or    too     little,     or     just 
enough    on    EDP? 

2.  Is    the   money   we  have    allocated  to    the  department    being 
properly    spent? 

To  answer  these  questions,  and  control  EDP,  top  manage- 
ment needs  two  key  structures.  The  first  is  a  financial 
reporting    system    that    allows    it    to  do    the   following    things: 

1.  Review    the    department's    performance    on    a    periodic 
basis . 

2.  Compare     the     department's     development     against     the 
formal    plans    for    it. 

3.  Check    the     functioning    of     the    department's    project 
control    systems. 

The    second    is    a    structure    that    links    the    responsibility 

for   various    departmental   decisions    to    the    operations    of    the 

users--ordinarily    other    company    departments.    Generally,    this 
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structure    is    a    procedure    to    account    for    EDP    expenses,     either 
on  a  charge-out  or  an  overhead  basis.    [Ref.   8:    pp.    70,    83] 

As  in  other  business  activities,  the  key  performance 
reporting  information  is  financial;  for  EDP  it  is  used  to 
track  both  the  department's  performance  against  its  own 
goals  (department  budget  and  project  control  system),  and 
the  degree  and  mix  of  its  support  to  the  other  departments 
(chargeback  system).  Two  weak  spots  in  financial  control 
systems  for  EDP  departments  have  been  project  control  for 
software  development  and  user  chargeback  systems  based  on 
computer  resources  and  terminology.  Developments  in  software 
cost  estimation,  like  Boehm's  COCOMO  (Cost  Control  Model), 
and  techniques  like  structured  programming  and  programmer 
teams  have  greatly  reduced  the  difficulty  of  estimating  and 
controlling  software  development  projects.  Computer-oriented 
chargeback  systems  which  give  users  detailed  reports  of  the 
CPU-seconds,  main  and  secondary  memory  units  used,  etc.,  are 
gradually  being  displaced  by  user-oriented  systems  as 
computer  services  become  crucial  to  the  "bottom  line"  of 
most  operating  divisions.  The  reasons  for  these  new  systems 
will    be    discussed    later. 

The     financial    basis     of    management    control    of     EDP 

departments  has   two   important    implications: 

1.  As  a  general  rule  management  control  systems  for  data 
processing  cannot  be  significantly  more  advanced  than 
the  management  control  systems  used  for  the  company  as 
a  whole.  Since  accounting  systems  provide  the 
foundation    for    management    control,    management    control 
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can    only     reflect    the     quality    of     the    accounting 
system."    [Ref.    9:    pp.    311,    315] 

2.  The  development  of  data  processing  accounting  systems 
is  initially  an  accounting  problem  rather  than  a  data 
processing  problem  because  basic  accounting  concepts 
are  most  important.  Unfortunately,  this  need  for 
accounting  skills  is  not  recognized  from  the  start. 
Usually,  technical  personnel  play  the  dominant  role  in 
designing  the  initial  DP  accounting  systems.  Rather 
quickly,  however,  it  becomes  apparent  that  the  real 
problems  are  financial  accounting  problems  concerning 
responsibility  centers,  costing,  and  allocating  costs 
to  responsibility  centers.  Accounting  personnel  are 
then   brought    into    the    project. 

These  fundamental  problems  seriously  hinder  the 
effective  design,  implementation  and  administration  of 
computer  use  chargeback  systems.  Simply  stated,  you  cannot 
build  a  sophisticated  control  system  on  a  sandy  foundation 
of    weak    accounting    systems.       [Ref.    9:    p.    315] 

1 .       Evolution  of    Chargeback    Systems 

Computer  chargeback  systems  were  originally 
accounting  devices  to  allocate  the  costs  of  a  very  large 
capital  investment  among  the  departments  that  used  it.  When 
most  of  the  processing  was  large  batch  jobs,  a  relatively 
simple  system  could  price  batch  jobs  according  their  use  of 
computer  resources,  as  reflected  in  reports  from  system 
monitor    programs. 

Differential  pricing  began  as  an  efficiency  measure, 
to  boost  use  and  distribute  the  workload  on  the  computer 
more  evenly  by  charging  less  for  jobs  run  during  the  evening 
and  night  shifts.  Once  the  computer  was  fully  scheduled 
(and    more)    it    became    a    scarce    resource;     prices    were    further 
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differentiated,  and  coupled  with  a  priority  system  for  the 
jobs  themselves,  to  control  and  monitor  the  competition  for 
the    now-scarce  computing    time. 

An  important  transition  was  made  as  the 
organization's  goals  changed  from  efficient  (full  use)  to 
effective  (most  necessary  jobs)  use  of  the  computer  system. 
The  management  control  purpose  of  the  chargeback  system  was 
expanded  to  include  shaping  the  behavior  of  users. 
Information  not  necessary  to  proper  computer  operation,  i.e. 
job  class  and  priority,  was  added  to  jobs  and  the  operations 
monitoring  programs  were  changed  to  record  it.  The  range  of 
choices  available  to  the  user  department  grew,  but  the  costs 
of  those  choices  were  determined  by  the  EDP  department,  and 
still  largely  based  on  recovering  the  actual  costs  of 
equipment    and    operations. 

A  priority  system  and  a  single  scarce  resource 
implies  that  some  jobs  never  get  scheduled.  An  alternative 
to  the  central  EDP  department  came  about  as  decreasing 
equipment  costs  allowed  time-sharing  and  computer  service 
bureaus  to  develop,  and  it  became  theoretically  possible  to 
get  all  computer  projects  accomplished  without  a  major 
capital  investment  decision.  Rather  than  competing  for  use 
of  the  single  company  computer,  projects  could  be  subjected 
to  the  same  cost/benefit  analysis  used  for  other  business 
projects  in  the  firm.  For  the  first  time,  make-or-buy 
analysis     (whether     to     do     a    job     yourself     or     buy     it     from 
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someone  else)  could  be  applied  also.  This  open  market  of 
competition  to  the  central  EDP  facility  radically  changed 
the  management  control  uses  of  the  chargeback  system  again. 
An  open  market  fosters  competition  through  price,  and  allows 
the  chargeback  prices  to  be  used  to  judge  how  ef  f iciently 
the  EDP  department  delivers  computer  services.  The 
responsibility  for  e  f f  ec ti ve  use  of  computer  services  was 
almost  totally  transferred  to  the  user  departments,  as  the 
organization's  experts  on  the  business  benefits  of  a 
particular  application.  Currently  organizations  require  the 
chargeback  system  to  isolate  as  completely  and  clearly  as 
possible,  the  actual  costs  of  the  specific  application.  The 
prices  must  be  refined  to  eliminate  the  variances  due  to  the 
operation  of  the  computer  department  from  the  actual 
consequences  of  the  "consumer's"  use.  This  provides  to  the 
user  the  best  cost  information  with  which  to  make  a  sound 
cost/benefit  decision  for  the  company.  Chargeback  is  also 
used  to  evaluate  the  user  for  efficiency  in  the  use  of 
computer  resources  in  accomplishing  his  or  her  business 
mission . 

Both  the  financial  accounting  and  the  computer- 
resource  accounting  abilities  of  the  organization  have  had 
to  mature  to  accomplish  the  expanding  management  control 
purposes  of  chargeback  in  an  increasingly  complex 
environment.  As  the  responsibility  for  effective  and 
efficient    use    of    computing    resources     shifts     to     the    user 
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departments,  they  have  demanded  that  charges  be  expressed  in 
units  they  can  understand  and  effect.  Applying  industrial 
accounting  techniques  allows  the  allocation  of  the  resource 
costs  per  job  (CPU-seconds,  tape  and  disk  drive  hours,  main 
and  secondary  memory)  to  be  priced  out  as  standard  costs  per 
work  unit  (cost  per  check,  per  invoice,  per  personnel  record 
update).  These  standard  costs  can  be  accumulated  by  section 
or  office  within  a  department  to  support  a  finer  degree  of 
control . 

The  implementation  of  management  control  through 
chargeback  is  a  dynamic  process.  Studies  of  the  process  have 
developed  four  criteria  for  judging  chargeback  systems: 

1.  Understandability : 

To  what  extent  can  the  manager  associate  charge-out 
costs  to  the  activities  necessary  to  carry  out  his  or 
her    tasks? 

2.  Controllability: 

To  what  extent  are  the  charges  under  the  control  of 
the   user? 

3.  Accountability: 

Are  costs  and  utilization  of  computer-based  systems 
included   in    the    performance   evaluation    of    the    user? 

4.  Cost/benefit  incidence: 

Does  the  user  responsible  for  task  accomplishment  also 
receive  the  chargeout  bill?  [Ref.  9:  p.  317] 

In  addition  to  evaluation  criteria,  these  studies 

have  produced  several  vital  general  observations.   One 

mistake  frequently  observed  in  designing  an  effective  system 

is  to  impose  sophisticated  controls  upon  organizational 

units  that  are  not  "ready".  The  organization  unit  is  not 


34 


ready  if  controls  hinder  its  operation  or  if  personnel 
cannot  clearly  see  the  relevance  of  the  controls  to  their 
problems.    [Ref.    9:     p.    311  ] 

Chargeback  systems  also  evolve.  They  initially  are 
directed  at  high-level  managers.  Summary  data  processing 
bills  are  sent  to  divisional  controllers  without  much 
information  on  the  charges  being  conveyed  to  end  users.  With 
maturity,  the  charge-out  systems  become  more  sophisticated 
and  permit  detailed  bills  to  be  sent  directly  to  low-level 
users.  It  is  important  that  a  chargeback  system  does  evolve 
through  successive  phases  so  that  users  and  DP  managers  can 
learn  how  to  interpret  and  use  the  information.  It  is 
especially  important  that  the  means  for  accountability  be 
coordinated  with  the  expectations  for  accountability.  Users 
resent    charges    for    systems    they    cannot    affect. 

Management's  objective  is  to  develop  a  strategy  that 
will  increase  the  maturity  (and  effectiveness)  of  the 
charge-out  system  at  an  appropriate  pace  for  the  major  user 
groups.  It  is  likely  that  several  charge-out  strategies  may 
be  required  for  the  different  user  groups.  [Ref.  9:  p.  318] 
2 .       Summary 

In    the    process    of   developing   management   controls    for 

the     Coast     Guard     IRM     architecture,      the     lessons     we     can 

transfer    from    the    experience    of    centralized   EDP    include: 

1.  Management  controls  for  EDP  are  financial  in  nature 
and  thus  comparable  to  the  controls  on  other 
departments . 
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2.  They  have  a  stronger  base  in  good  accounting  than  in 
technology.  They  can  therefore  be  no  more  complex  than 
the  accounting  and  management  control  systems  of  the 
rest    of    the    organization. 

3.  A  chargeback  system  is  essential  to  management  control 
of    EDP   departments,     and   eventually,     EDP   users. 

4.  Chargeback  schemes  grow  and  mature.  Management  must 
develop  a  strategy  to  manage  this  process  at  an  rate 
appropriate  to  the  major  user  groups,  and  to  changing 
management    control    needs. 

An    important     although    not     obvious     point     is     that     the 

competition   for    computer   services    described    here    takes    place 

in     essentially    a     single    arena.        The    goods    and    services 

(reports,    database    queries,    CPU    cycles)    are    almost    perfectly 

interchangeable,     between    the    daytime    on-line    version   of    the 

payroll   and    the    late    shift    batch    run   of    the    same    program, 

even    between    the    in-house    product    and    the    service    bureau 

version    of    the    same    printout.       Competition    by    price    is    a 

logical    basis    of    comparison   of    subs ti tu table  goods    in    the 

same    open    market,     whether    in    keeping    the    EDP    department 

'honest',     or     in    the    user's    trade-off    between    alternate    ways 

of    implementing   a    given   project.    As    a    management    control 

technique,     it    assumes    that    everyone    knows    all    the    prices 

(perfect     knowledge)     and     knows     the     subs ti tutabi li ty     of 

various    goods,      so    changing    the    relative    pricing    should 

logically    effect    behavior. 

C.       EXPANDING    EDP    TO    IRM    AND    REFINING    CHARGEBACK 

Information    resource    management    obviously    entails    more 
than    controlling    a    centralized    data    processing    center.     The 
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Coast     Guard     has     defined     it     to     include    all     information 

processing:      transactional     and     operational     information, 

office    automation    as    well    as    data    processing    and    voice    and 

data   telecommunications.    This   expansion   means   it   includes 

what     Strassman     defines     as     a     second     major     sector     of 

information    processing,      "administrative     processing",      which 

he     says     is     largely     ignored    by     information-processing 

executives : 

"While  it  accounts  for  the  largest  and  most  frequently 
used  set  of  tools  and  facilities  for  handling  information 
transactions,  it  is  rarely  aggregated  under  a  single 
expense  heading.  It  includes  everything  from  typewriters, 
word  processors  and  dictating  equipment  to  telephone  and 
Telex  networks,  recording  devices,  copiers  and  duplica- 
tors, facsimile  transmission  devices,  microfilm  equipment, 
and  even  such  relatively  mundane  necessities  as  office 
supplies,  mail,  and  simple  filing  systems.  These  adminis- 
trative tools  are  quite  diverse  and  often  isolated  from 
one  another,  so  that  the  expense  involved  in  their  use 
tends  to  become  highly  diffused.  Historically,  little 
trade-off  has  been  possible  among  such  individual  office 
"technologies".      [Ref.   9:    p.   2  95]" 

No   organizational    unit    is    responsible   for    integrating 

these    noncomputer    aspects    of    information    handling,     but     the 

fastest    expense     growth     in     the    office    environment     is 

occurring   here.    If    an    organization    intends    to    control    rising 

expenses    for    'white-collar    automation',     information    systems 

management   must    expand  to    include  careful    expense    accounting 

for    these    diverse    office    technologies.    This    control    must 

also   be    in    some    flexible   automated   form,    since   the    future 

volume    of    information    transactions    is    uncertain,     as    are    the 

relative    importance    of    various    cost    elements,     rapid    changes 
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in    technology,     and     shifting     attitudes    toward     office 
automation   by    labor    and   government.       [Ref.    9:     p.     296] 

In  addition  to  the  increased  size  of  the  total 
information  system,  and  a  greatly  increased  number  of 
transactions,  we  are  annexing  an  area  where  the  costs  are  so 
spread  out  as  to  be  hard  to  accumulate.  The  management 
control  job  will  be  further  complicated  by  the  lack  of 
direct  tradeoffs  between  the  products  of  some  of  the 
subsystems  in  the  architecture.  For  a  price-based  control 
system  to  work,  some  indirect  measure  of  subst itutabil ity 
among  the  systems  will  have  to  be  developed.  Considering  the 
massive  volume  of  transactions,  the  entire  control  system 
must  be  eventually  completely  automated.  It  is  more 
appropriate  to  call  it  an  'information  pricing  system1 
rather  than  'chargeback'.  A  good  encapsulation  of  the 
ultimate  goals  of  such  a  control  system  is  Strassman's  list 
of  the  objectives  for  a  top  information  executive  in  today's 
business    environment: 

*  Ensuring  the  integration  of  data  processing,  adminis- 
trative processing,  and  office  labor  productivity 
programs . 

*  Instituting  accounting,  cost-control,  and  budgeting 
innovations  that  will  subject  all  information  systems 
overhead  activities  to  the  disciplines  traditionally 
applied    to    direct    labor. 

*  Subjecting  office  labor  automation  programs  to 
analyses  comparable  to  those  applied  to  all  other 
forms    of    capital    investment. 

Conceiving    organizational    designs    that    will    permit 
information    to    be    handled    as    a    readily    accessible    and 
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easily    priced    commodity    rather    than    as    a    bureaucratic 
possession . 

*  Creating  within  the  organization  an  internal  market 
for  alternative  information  systems  products,  so  that 
trade-off  decisions,  even  technologically  complex 
ones,  can  be  decentralized  into  the  hands  of  local 
user   management. 

*  Fostering  a  technique  of  pricing  that  will  allow 
decisions  on  introducing  new  technology,  or  abandoning 
obsolete  technology,  to  be  made  on  a  decentralized 
basis . 

*  Installing  and  monitoring  measurement  methods  that 
will  protect  improvements  in  productivity  achieved  by 
automation    programs. 

These  are  the  ultimate,  not  the  immediate,  goals  of  any 
proposed  management  control  system  for  a  complete  informa- 
tion system.  By  examining  the  purposes  and  evolution  of  EDP 
chargeback,  and  projecting  the  requirements  for  information 
systems  control  for  the  future,  we  have  set  the  stage  for 
considering  specific  recommendations  for  management  control 
requirements  of  the  Coast  Guard  Information  Resource 
Management   Architecture. 
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IV.       CONTROL    REQUIREMENTS    OF    THE    ARCHITECTURE 

A.       SUGGESTED    MANAGEMENT    CONTROL    REQUIREMENTS    FOR    THE    COAST 
GUARD   INFORMATION    RESOURCE  MANAGEMENT  ARCHITECTURE 

To  pave   the  way   for    a   smooth   transition   to   the    control 

stage     of     computer    growth,      the    Coast     Guard    should    soon 

develop    the    information    or    systems    necessary    to    meet    the 

following   five    requirements: 

1  .      Aggregate    financial    information 

2.  Auditable    identification   of    users 

3.  Meaningful    chargeback   system(s) 

4.  An    'information   marketplace' 

5.  An    information   decision-making    tool 

Each  of  these  will  be  explained  in  detail  below.  These 
suggestions  assume  that  major  hardware  subsystems  (i.e. 
mainframe  or  minicomputers,  communications  network 
interfaces)  will  have  resource-accounting  monitor  programs 
installed. 

1 .      Aggregate    Financial    Information 

Since  the  primary  support  of  budget-based  management 
control  systems  is  good  accounting,  the  Coast  Guard 
accounting  system  should  be  modified  to  allow  for 
information  costs  to  be  aggregated,  both  by  organizational 
unit,  (i.e.  a  Division  or  a  Section  of  a  District  Office) 
and    by    a    project    identifier     (Project    D17-21 ,     Develop 
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Operations  Database).  The  current  joint  project  of  the 
Office  of  C^  and  the  Office  of  the  Comptroller  to  develop 
and  automate  a  Coast  Guard  Standard  Accounting  System  should 
address  whether  a  separate  Operating  Guide  (OG)  or  a  Subhead 
is  needed  to  identify  information  funds,  or  whether  an 
Object  Code  identifier  holds  enough  information  and 
flexibility  for  complex  financial  reporting.  A  unique 
identification  of  the  funds  as  information  funding,  along 
with  a  system  or  project  identifier,  and  a  capability  to 
retrieve  by  organizational  subunit  will  support  the  reports 
necessary  to  monitor  and  control  both  the  IRM  function  and 
the  end  users.  An  identifying  field  of  this  sort  would 
support  "information  budgets"  easily  when  cost  control 
becomes  necessary.  It  also  would  function  partially  as  a 
common  denominator  for  the  information  services,  supporting 
tradeoff  decisions  and  preserving  information  savings  for 
the  inf or  ma t ion -e f f i c ien t  manager  to  spend  on  other 
information    services. 

2 .   Auditable  Identification  of  Users 

A  basic  concept  in  any  branch  of  accounting  is  the 
audit  trail,  the  ability  to  reconstruct  for  any  entry  in  the 
record,  the  series  of  transactions  that  originated  or 
altered  it.  Conversely,  for  any  original  entry  or 
transaction  the  audit  trail  tells  you  which  permanent 
records  it  affected.  The  financial  nature  of  management 
control     that     we     have     developed     insists     that     the       user 
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authorization  and  identification  structures  used  in  the 
various  subsystems  of  the  IRM  Architecture  be  auditable, 
that  they  maintain  or  can  reconstruct  a  complete  audit  trail 
from    end    user    to    ultimate    database. 

In  addition  to  insuring  auditability  of  IRM 
financial  accounting  and  chargeback,  an  auditable  user 
identification  scheme  reinforces  system  security,  and  by 
increasing  the  perceived  threat  of  apprehension,  strengthens 
the  policy  and  procedure  controls  of  the  system.  Another 
perception  that  benefits  from  secure  identification  is  the 
perceived  equity  of  the  chargeback  system.  Since  not  all 
users  nor  all  applications  can  be  equally  important  to  the 
organization,  the  most  a  chargeback  system  can  hope  for  is 
"perceived  equity".  [Ref.  10:  p.  260]  An  auditable  access 
scheme  documents  for  the  user  that  the  charges  received  did 
originate  in  his/her  department,  and  reinforces  a  perception 
of    equity. 

The  high  degree  of  telecommunications  in  the  IRM 
Architecture,  with  some  systems  open  to  several  networks, 
means  that  simple  password  systems  will  not  provide  adequate 
protection.  This  communications  vulnerability  is  aggravated 
by  the  periodic  transfers  of  the  Coast  Guard's  military 
personnel.  User  accounts  are  often  only  logical  partitions 
in  the  same  computer,  accessed  by  a  network  common  to 
several  physical  user  sites.  Passwords  could  not  protect  a 
filespace    from    an   old    authorized   user    at    a    new    duty    station. 
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Some  hardware  identification  (such  as  a  terminal  identifier) 
at  least  needs  to  be  added  to  all  systems.  To  preserve  the 
audit  trail,  space  for  this  terminal  identifier  and  the  user 
i.d.  needs  to  be  designed  into  network  message  headers.  Once 
the  access  and  message  header  configurations  are  frozen,  the 
incremental  costs  of  adding  security  and  auditability  will 
be  much  higher,  as  will  the  temptation  to  forego  the  expense 
and  rely  on  procedures  alone  for  control. 
3 .   Meaningful  Chargeback  System( s ) 

The  goals  of  a  meaningful  chargeback  system  are  to 
express  the  costs  of  information  in  the  terms  of  the  user's 
units  of  work,  and  to  understandably  identify,  accumulate, 
and  return  to  the  user  all  information  costs  associated  with 
his/her  work  operations.  Ultimately,  such  a  system  would 
completely  satisfy  all  four  of  the  evaluation  criteria 
listed  in  Chapter  III.  The  system  administrative  overhead 
necessary  for  the  financial  reporting  and  user 
identification  requirements  just  discussed  will  also  enable 
a  user- or iented  chargeback  system  to  be  implemented,  as  a 
third  benefit  to  offset  those  same  costs. 

One  possible  implementation  of  such  a  chargeback 
scheme  is  as  an  interface  accounting  program,  which  would 
accept  inputs  from  the  various  subsystems,  sort  them  by  user 
identification,  cross  reference  with  user  budgets  and 
transaction  totals,  and  produce  a  average  cost  per 
transaction  type,  detailed  to  identify  information  subsystem 
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costs.  Such  a  system  would  have  to  be  both  modular  and 
flexible  by  design,  to  allow  subsystems  to  be  added  and 
removed  as  configurations  and  technology  changed.  Locating 
it  as  close  to  the  user  as  possible  in  the  architecture 
would  allow  all  higher  systems  to  run  "off-the-shelf" 
computer  resource  monitors,  modified  only  enough  to  record 
both  user  and  terminal  identifications. 
4 .      An    Information   Marketplace 

Users  could  make  trade-off  decisions  rather  easily 
when  the  services  were  all  available  from  one  source  (the 
EDP  department),  or  even  were  direct  substitutes  for  each 
other  (service  bureau  versus  in-house,  for  the  same 
product).  The  number  of  alternative  information  services, 
and  the  number  of  ways  to  obtain  them  are  both  growing 
rapidly,  even  within  the  unifying  device  of  the  IRM 
Architecture.  Strict  dollar  cost  is  not  an  accurate  basis 
for  comparison  or  competition  any  longer.  The  C  Support 
Program  Plan  identifies  timeliness,  quality  (accuracy  and 
precision),  quantity,  and  cost  (of  collection,  transmission, 
storage,  and  use  )  as  components  of  information  of  interest 
to  the  Coast  Guard  [Ref.  2:  p.  5-1].  Few  among  user 
management  will  have  the  information  judgement  to  evaluate  a 
straight  cost  for  service  against  its  value  along  those  four 
parameters.  Some  set  of  adjusted  prices,  or  factors  by 
which  to  weight  costs  will  be  necessary  to  create  an 
information    marketplace    where    products    and     services    of     the 
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various  information  subsystems  can  be  directly  compared. 
The  user  is  the  expert  on  the  benefits  to  his  program  that 
the  service  will  provide;  the  architecture  will  have  to 
provide  him/her  a  basis  for  properly  comparing  and 
evaluating  the  costs  of  that  service,  if  the  Coast  Guard 
intends  to  hold  the  user  accountable  for  an  effective  and 
efficient  decision.  This  could  be  as  simple  as  a  set  of 
adjusted  prices  for  a  generic  example,  (i.e.  the  average 
letter  costs  2.6  times  as  much  as  a  message)  coupled  with 
substitution  rules  and  judgement  criteria  (letter  vs 
message:  consider  speed  and  security),  or  as  complex  as  a 
database  of  currently-calculated  weighting  factors  available 
to    an   automated   decision-making    tool. 

5 .   An  Information  Dec is ion -making  Tool 

In  addition  to  creating  the  information  marketplace 
by  publishing  a  list  of  adjusted  or  general  substitution 
prices,  the  system  should  provide  a  consumer's  guide  to 
proper  shopping.  This  will  insure  the  most  effective 
accomplishment  of  the  IRM  architecture's  management  control 
mission    through    pricing    and    chargeback. 

It  is  to  the  Coast  Guard's  advantage  to  have  users 
making  the  most  effective  and  efficient  information 
decisions  possible.  The  user/manager  is  best  qualified  to 
make  the  cost/benefit  comparison  of  alternative  information 
services.  The  goal  of  the  chargeback  system  is  to  provide 
that    user/manager    the    best    possible    cost     information    to 
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combine  with  his  best  possible  benefit  knowledge,  and  then 
hold  him  accountable  for  the  decision.  The  manager  will 
develop  an  information  decision  'support  system'  for  these 
decisions,  if  only  a  set  of  notes  on  how  the  last  one  was 
done.  There  will  be  a  faster  learning  curve  and  more 
consistent  results  if  the  IRM  architecture  recognizes  this 
and    supports    the   manager's    decision   by    some    standard   means. 

A  published  set  of  sugge.sted  procedures  (cookbook 
guide)  could  couple  with  a  price  list  to  produce  trade-off 
decisions  standard  enough  to  be  comparable  and  reproducible. 
Eventually,  a  spreadsheet  program  able  to  access  a 
substitution  price  table,  or  to  calculate  weighted  prices 
from  the  chargeback  information  could  be  developed.  Some 
project  lifecycle  guidelines  could  be  incorporated  in  such  a 
program  painlessly.  In  whatever  manner,  some  decision 
support  should  be  developed.  To  have  management  control 
through  pricing  and  chargeback  work  properly,  we  assume  the 
goods  are  subs ti tutable ,  and  the  consumers  have  perfect 
knowledge  of  both  price  and  s ubst itutabil ity.  We  further 
assume  they  will  make  the  logically  best  choice.  These  last 
two  suggestions  for  the  IRM  architecture  (information 
marketplace  and  decision  support)  attempt  to  insure  those 
assumptions  are  met,  and  to  assist  the  user  in  the  choice 
best    for   his    unit    and    for    the    Coast    Guard. 
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B.   IMPLEMENTATION  SUGGESTIONS 

1 .   The  Standardized  User  Interface 

In  a  system  as  large  and  as  distributed  as  the  Coast 
Guard  IRM  Architecture,  operating  under  Federal  rules  for 
competitive  procurement,  it  is  almost  certain  that  the 
various  subsystems  (both  hardware  and  software)  will  be 
developed  separately.  Unless  specifically  controlled,  the 
interface  each  subsystem  presents  to  the  user  will  vary  from 
one  subsystem  to  another.  The  interface  includes  such  things 
as  the  location  and  size  of  text,  the  method  of  specifying 
commands  (numbers,  letters,  words),  the  method  of  presenting 
options  (text  or  a  menu)  and  other  guidelines  to  the  user 
for     input. 

At  the  extreme  range  of  variation  of  these  inter- 
faces, an  identical  command  will  have  different  meaning  and 
effect  in  two  different  systems  which  a  single  user 
routinely  accesses.  (For  example,  STOP  in  one  system  halts 
text  scrolling  on  a  display  screen,  in  another  it  ends  the 
session. ) 

Specifying  a  standard  user  interface-  to  be 
maintained  by  all  subsystems  simplifies  learning  and  use  of 
the  entire  coordinated  system  greatly.  It  provides  a 
mechanism  for  the  smooth  introduction  of  change  as  well,  by 
preserving  for  the  user  as  much  of  the  familiar  as  possible 
as  an  environment  for  the  new  function  or  command.  A  major 
advantage    is    that    once    an    effective    user    interface    for    a 
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given  system  or  subsystem    is  developed,    that  design  can  be 

'frozen'     from     change     for     a     while,      preserving     the 

effectiveness    of    the    interface    through    other    system    changes. 

We   have    seen   that    chargeback   and    management    control    systems 

change    to    match    the    maturity    and    growth    of    the    information 

system    overall.     Expecting     that     change,     a    standard    user 

interface     should     be     developed     and     incorporated     in     all 

automated    portions    of     the    control     structure    of     the     IRM 

architecture . 

2.       Prototype/ Iterate/ Adapt 

We    have    already    characterized    portions    of     the 

proposed     management      control      structure      for     the      IRM 

architecture    as    a    decision    support    system    for    the   user   in 

purchasing     information    services.       That    tool    could       also 

function    as    a    decision    support    system    for    the    organization 

in  choosing    those  prices    which   will    produce    the   desired   user 

behavior.      A   proposed    new   price   for  a   single   service  could 

be   tested  by  running   the  user's  decision    tool    program    with 

that    price    as    an    input.    The    price    could    be    adjusted    until 

the   desired   decision   was    reached,     or    the    model    could   be    run 

'backward'    to    determine    the    specific    price    change    required. 

Developing    the    Coast    Guard    IRM    management    control    structure 

shares      much     with     the     development     of     decision     support 

systems,     as    characterized    by    Keen    [Ref.    11:    p.    132]: 

*        Neither     the      user     nor      the     builder      can     specify 
functional    requirements    in    advance. 
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*  Users  do  not  know,  or  cannot  articulate  what  they  want 
and  need.  They  need  an  initial  system  to  react  to  and 
improve  upon. 

*  The  users'  concept  of  the  task  and  perception  of  the 
nature  of  the  problem  changes  as  the  system  is  used. 

*  Actual  usages  (of  DSS  )  are  almost  always  different 
from  the  original  intended  ones.  In  fact  case  studies 
show  that  many  of  the  most  valued  and  innovative  uses 
could  not  have  been  predicted  when  the  system  was 
originally  designed. 

*  Intended  users  of  the  system  have  sufficient  autonomy 
to  handle  the  task  in  a  variety  of  ways,  or  to  differ 
in  the  way  they  think  to  a  degree  that  prevents 
standardization  of  process. 

Several  studies  [Refs.  12,  13,  14]  suggest  that  the  best 

method  for  designing  a  system  in  such  a  loosely-defined 

situation  is  by  an  iterative  design  process.  The  steps  in 

the  process  include: 

1 .  Identify  an  important  subproblem. 

2.  Develop  a  small,  but  usable  system  to  assist  the  user. 

3.  Refine,  expand  and  modify  the  system  in  cycles. 

4.  Evaluate  the  system  constantly. 

This  design  approach  starts  with  an  prototype  system,  which 
adapts  in  successive  iterations  to  the  user's  and  the 
designer's  experiences.  By  definition  it  is  flexible  and 
adaptable.  This  method  is  proposed  as  a  design  alternative 
to  classic  system  life  cycle  design,  which  attempts  to 
define  all  possible  system  requirements  in  the  initial  study 
phase,  and  then  delivers  a  specific  system  to  satisfy  those 
requirements.  A  major  change  in  such  a  system  requires  a 
return    to    the    study    phase    and    a    new    set    of    requirements.      An 
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advantage  of  iterative  design  is  that  several  different 
small  prototypes  can  be  run  in  parallel,  and  evaluated 
before  selecting  a  standard  model  for  system-wide 
implementation    testing. 

The  various  programs  and  systems  to  satisfy  the 
management  control  requirements  previously  listed,  with  the 
single  exception  of  the  structure  for  aggregation  of 
financial  information,  should  be  developed  using  this 
iterative  design  methodology.  The  complex  and  ill-defined 
nature  of  the  control  problem,  plus  the  need  for  the  control 
system  to  continually  grow,  support  using  a  method  focused 
on   development    of    poorly   defined    and    flexible    systems. 

The  appropriate  place  to  initially  install  the  prototype 
systems  to  begin  satisfying  the  proposed  management  control 
requirements  is  at  the  level  of  the  District  Office,  for  a 
number  of  reasons  which  will  be  fully  developed  in  the  next 
chapter.  An  implementation  incorporating  several  of  the 
necessary  control  elements  into  a  District  Office  Local  Area 
Network   will    also    be   described. 
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V.   THE  DISTRICT  OFFICE  LOCAL  AREA  NETWORK 
IMPLEMENTATION  OF  MANAGEMENT  CONTROLS 

A.   WHY  THE  COAST  GUARD  DISTRICT  OFFICE 

The  major  reason  for  placing  the  management  control 
structures  of  the  Coast  Guard  IRM  architecture  at  the  level 
of  the  District  Office  is  to  remain  congruent  with  the  rest 
of  the  organization.  The  District  Office  exercises  manage- 
ment control  over  every  other  operational  program  and  staff 
function.  In  the  financial  chain,  for  example,  the  District 
Comptroller  approves  operating  unit  budgets  with  the 
concurrence  of  the  district  program  manager.  For 
administrative  information  control,  all  official 
correspondence  and  reports  enroute  from  operating  units  to 
Headquarters  must  be  endorsed  by  the  district  program 
manager  in  the  chain  of  command  for  the  originating  unit. 
Management  control  of  the  information  program  logically 
belongs    at    the    District    Office    as    well. 

The  District  Office  is  the  level  at  which  hierarchical 
information  is  aggregated  for  forwarding  to  Headquarters,  as 
illustrated  in  Figure  3.  The  Coast  Guard  District  block  in 
the  IRM  architecture  (as  illustrated  in  Figure  1)  is  also 
the  system  node  with  the  most  connections  to  other  networks 
and    units.    This    center    of    connectivity    is    the    best    place    to 
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easily  collect  a  maximum  amount  of  data  about  computer  and 
communication  systems    usage. 

With  the  installation  of  minicomputers  in  each  of  the 
twelve  Coast  Guard  Districts  scheduled  for  FY  86,  the 
processing  power  will  be  available  to  run  the  monitor, 
accounting  and  user  identification  programs  necessary  to  the 
prototypes.  There  will  also  be  sufficient  data  storage 
capacity  available  to  accumulate  an  historic  data  base  on 
usage   and    usage    patterns    for    information    services. 

People  resources  are  at  the  District  Offices  as  well. 
The  District  IRM  officers  are  in  place  with  the  knowledge  to 
run  and  evaluate  the  prototype  control  systems.  The  other 
district  program  managers  make  up  a  team  of  knowledgeable 
control-oriented  managers  ready  to  fully  test  the  various 
prototypes  and  suggest  changes.  Because  of  these  program 
managers,  the  IRM  control  problem  at  the  District  office 
will  be  the  most  difficult,  and  therefore  the  richest  in 
terms    of    potential    learning    about    user    requirements. 

The  district  program  managers  are  management  controllers 
themselves,  of  units  and  programs  for  a  geographic  area.  A 
major  mission  of  the  district  IRM  staffs  will  be  teaching 
them  how  to  use  information  services  in  exercising  that 
management  control.  As  the  need  for  control  of  the  IRM 
architecture  grows,  the  district  IRM  staff's  job  will  become 
controlling  these  other  controllers,  and  through  them  their 
units,-    to     promote     more    efficient     and    effective     use     of 
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information  services.  The  district  IRM  office  is  the  turning 
point  at  which  control  within  the  vertical  structure  of  the 
information  program  (the  IRM  architecture)  must  translate 
into  horizontal  control  (by  the  district  IRM  staff)  of 
resource  distribution  and  use  out  to  the  district  managers 
of  other  programs.  They  are  the  logical  office  to  task  with 
calculating  and  distributing  the  chargeback  bills  to  the 
district  program  managers,  both  for  information  services 
received  from  the  District,  and  for  an  allocated  portion  of 
other  services  (i.e.,  HQ  database  usage)  being  billed  to  the 
District.  These  bills  will  be  a  primary  control  device  of 
the  architecture.  The  user  is  understandably  apt  to  feel 
unfairly  treated  when  the  people  who  developed  and  fed  his 
growing  dependence  on  information  services  begin  blaming  him 
(holding  him  cost  responsible)  for  overuse  of  those  same 
services.  Early  placement  of  the  control  structures  would 
allow  tactics  such  as  distributing  'educational'  chargeback 
bills  which  remind  users  that  they  are  not  using  a  free 
good.  It  would  also  make  a  usage  history  available  when  the 
first  aggregated  chargeback  bills  to  the  District  show  up 
from  the  Headquarters  databases,  to  substantiate  equitable 
apportionment  of  the  cost  by  the  District  IRM  staff. 

The  District  Office  is  the  node  of  the  Coast  Guard  IRM 
architecture  where  it  all  comes  together.  Satisfying  the 
management  control  requirements  of  that  architecture  at  the 
District  Office  level  is  the  crucial  problem  for  control  of 
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the  architecture  overall,  and  an  early  start  on  the  problem 
may  ease  a  difficult  transition  from  teacher  to  tax  man  for 
the   district    IRM    staff    later    on. 

B.       WHY    THE    LOCAL    AREA    NETWORK 

Throughout    the    thesis    we    have  been   attempting   to   develop 

the    need    for,      and     requirements     of,      management     control 

structures    for    the    entire    Coast    Guard    IRM    Architecture,     as 

one    large    but    integrated    system.     That     integration    is    an 

express    intention    of    the   Office    of    C   . 

"The  IRM  architecture  and  other  policies  of  the  (Office  of 
C  )  program  discourages  the  proliferation  of  field-unit 
terminals  connected  independently  to  s i ng le -  program 
central  data  bases.  This  would  be  an  electronic  version 
of  our  present  uncoordinated,  overlapping,  manual 
information    system."    [Ref.     1:    pp.     4-7] 

While  the  management  control  requirements  we  have 
developed  are  applicable  and  useful  to  any  of  the  single 
vertical  information  systems  within  the  overall  architecture 
(e.g.  Personnel  Management  Information  System  (PMIS),  Marine 
Safety  Information  System  (MSIS)),  they  are  also  powerful 
devices  for  logical  integration  of  these  separate  systems 
into  a  single  architecture,  from  the  user's  point  of  view. 
To  accomplish  this  integration,  the  controls  must  be 
applied,  or  at  least  appear  to  the  user  to  be  applied,  as  a 
single    part    of    a    unified   architecture. 

To  those  who  have  read  the  various  planning  and  support 
documents  of  the  IRM  architecture,  it  is  a  logical  whole, 
and   its   integration  of   systems   is  obvious.    However,    if    the 
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user  of  the  system  confronts  a  different  interface  screen 
and  different  sign-on  procedure  for  each  of  the  subsystems 
(PMIS,  MSIS)  he  or  she  uses,  and  if  each  of  these  subsystems 
returns  a  separate  chargeback  bill  which  the  user  must 
"integrate"  with  a  hand  calculator,  then  the  IRM 
architecture    has    not    achieved    its    'single    system1    goal. 

The  single  physical  device  connecting  all  the 
information  resources  of  the  CG  District  block,  in  the 
Figure  1  illustration  of  the  architecture,  is  the  'local 
net',  the  District  Office  Local  Area  Network  (LAN).  When 
fully  operational,  this  local  net  will  be  the  port  through 
which  all  district  information  services  can  be  accessed. 
Application  of  the  IRM  architecture's  management  controls 
through  the  LAN  uses  its  physical  integrating  power  to 
create  and  reinforce  the  logical  unity  of  the  overall 
system.  It  collects  the  separate  shopkeepers  of  the 
individual  information  systems  into  an  information 
marketplace  where  control  through  pricing  can  be  most 
effective    for    the    entire    architecture. 

C.       MEETING    THE    REQUIREMENTS    WITH    THE    LAN 

Each  of  the  management  control  requirements  will  be 
discussed  separately  below  for  a  configuration  that  assumes 
an   operating    local    area    network    is    in    place. 
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1 .  Aggregate    Financial    Information 

While  no  physical  program  or  device  is  needed  to 
satisfy  this  requirement,  the  necessary  changes  to  the 
financial  accounting  structure  will  need  to  be  defined 
before  the  design  configuration  is  frozen  for  other, 
automated  portions  of  the  control  structure.  The  accounting 
changes  may  add  extra  data  items,  or  expand  the  size  of 
existing  data  items,  throughout  the  architecture,  to  ensure 
that  the  information  necessary  for  the  audit  trail  and  for 
pro j ect - level  aggregation  of  information  costs  is 
maintained.  For  example,  adding  a  field  to  a  message  header 
to  hold  a  project  identification  may  change  hardware  and 
software    throughout    the    system. 

2.  Auditable  User  Access 

The  District  LAN  is  the  IRM  system  entry  port;  user 
and  terminal  identification  should  be  demanded  and  tested 
here.  This  begins  and  maintains  the  audit  trail  at  the  point 
of  first  entry  for  all  users  at  or  below  the  District  Office 
level.  Once  the  user  is  authorized  access  to  the  network, 
the  network  can  then  access  all  subsequent  communications 
links  and  computers,  providing  the  appropriate  access 
information  and  identifying  the  user  and  terminal  to  the 
other    systems. 

This  eliminates  the  problem  to  the  user  presented  by 
a  multitude  of  different  access  procedures  for  each  of  the 
different    intermediate    services.     For    example,     to    access    the 
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Operational  Information  System  computer  in  New  York,  the 
user  must  dial  the  local  number  of  GTE  TELENET,  and  comply 
with  their  sign  on  procedures,  providing  an  account  number 
and  a  password,  then  requesting  the  connection.  Once 
connected  to  the  OPINS  computer,  a  minimum  of  three  more 
i.d.  and  password  combinations  are  necessary  to  reach  a 
working  level  successfully.  The  importance  of  the  informa- 
tion involved  justifies  the  security,  but  the  tedium  to  the 
user  has  prompted  the  OPINS  configuration  managers  to 
authorize  an  programmable  modem  (computer  communications 
device)  to  be  installed  in  their  systems.  This  modem  then 
allows  a  user  to  access  the  remote  computer  with  the  push  of 
a  single  button.  The  protocols,  identification  numbers  and 
passwords  are  all  programmed  into  the  modem,  and 
automatically  presented  to  the  necessary  subsystems.  The 
audit  trail  is  lost--the  system  cannot  record  a  unique 
identification  (number,  password  and  terminal  i.d.)  of 
whichever     user      pushes      the      button.  Satisfying      the 

requirement  for  auditable  user  identification  at  the  initial 
access  to  the  District  LAN  would  preserve  the  utility  of 
automation  such  as  this  while  not  losing  security  or 
audi tabi li ty .  Overall  system  security  would  actually 
increase  by  recording  the  user  identification  data  provided 
to  the  LAN  by  people  repeatedly  attempting  access  to  systems 
for   which    they   were    not    authorized. 
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This  automation  provides  more  than  user  convenience. 
The  various  information  subsystems  (PMIS,  MSIS)  are  reached 
via  different  communications  networks,  and  once  accessed 
have  different  password  procedures  and  file  structures.  If 
the  user  must  record  and  maintain  the  access  information  for 
each  system  separately,  then  the  fact  of  their  separateness 
as  subsystems  is  reinforced  each  time  any  subsystem  is 
accessed.  If  the  various  subsystems  all  appear  as  selections 
on  an  "Access  Menu"  once  the  user  has  signed  on  to  the  LAN, 
they   are    reinforced   as    parts    of    a    unified    system. 

One  alternative  to  LAN  user  identification  data 
capture  is  distributing  unique  identifiers  and  passwords  for 
all  individual  units  at  the  destination  end,  (i.e.  OPINS  ) 
and  auditing  use  for  chargeback  there.  Administering  both  a 
billing  and  a  password  maintenance  system  adds 
administrative  overhead  at  the  highest  level  of  the 
architecture.  Collection  of  the  usage  data  is  removed  from 
the  level  of  enforcement  of  the  charges,  and  the  user's 
perception  of  autonomy  and  system  equity  may  suffer. 
3 .      Meaningful    Chargeback    System 

A  meaningful  chargeback  system  provides  information 
useful  to  the  user.  While  the  initial  chargeback  systems 
will  not  be  refined  enough  to  track  each  user  in  detail  and 
express  all  costs  in  terms  of  the  user's  work  units,  the 
'useful  information'  goal  can  be  preserved  during  the 
iterative   development    of    the    chargeback    system,    and    this 
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function,  too,  can  reinforce  the  concept  of  unity  for  the 
architecture. 

For  example,  consolidating  and  keeping  track  of  the 
separate  information  service  charges  against  a  user 
division's  total  information  budget  (telephone,  Xerox, 
microcomputer  supplies  and  maintenance,  etc.)  would  be 
useful  to  the  user  while  reinforcing  logical  integration  of 
these  (now)  diverse  services.  A  program  available  through 
the  network  to  extract  such  accounting  data  for  a  given 
user,  producing  an  up-to-the-minute  status  for  his/her 
information  budget  would  do  much  to  associate  resource 
accounting  with  information  rather  than  bills.  Such  a 
program  would  only  require  a  standard  query  to  the 
accounting  database  on  the  District  minicomputer.  Having  the 
program  available  through  the  LAN  allows  IRM  managers  to 
track  how  frequently  the  program  is  used,  as  a  rough  guide 
to  the  'information  awareness'  of  the  entire  staff  or  a 
given    division. 

Often,  before  actual  charges  for  system  use  are 
levied,  the  chargeback  system  is  used  as  a  device  to  notify 
users  of  the  level  and  cost  of  the  information  service  they 
consume.  [Ref.  15:  p.  114].  As  each  of  the  various 
subsystems  gains  resource  accounting  and  reporting 
capabilities,  their  usage  data  could  be  added  to  the 
chargeback  or  'budget  status'  report.  The  transition  to 
actual    charges    would    be    a    gradual    change,    and    the    user    could 
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judge  both  charges  and  usage  data  in  context.  The  single 
budget  report  (bill)  would  reinforce  the  logical  system 
unity,  and  the  LAN  could  make  it  a  recordable  and  easily 
accomplished    event. 

4 .      An    Information   Marketplace /Dec is ion   Tool 

The  marketplace  concept  is  an  attempt  to  identify 
the  functions  and  costs  of  the  information  services,  and  to 
identify  the  substitutions  possible  between  them.  It  intends 
to  develop  in  the  user  a  holistic  view  of  information 
processing  and  to  influence  his/her  conduct  with  pricing. 
If  functionally  similar  services  are  available  through  the 
LAN  as  a  series  of  substitution  lists  or  function  menus,  the 
physical  presentation  strongly  reinforces  the  logical 
integration  and  substitutability  the  management  controls  are 
trying  to  develop.  Rather  than  remembering  that  electronic 
mail  and/or  record  communications  messages  can  substitute 
for  hard  copies  on  letterhead  stationery,  the  user  chooses 
one  or  the  other  from  an  "Output  Menu"  and  the  network 
delivers  the  user's  document  to  the  appropriate  device.  Or, 
the  user  could  select  several  options  and  compare  their 
prices  before  committing  the  document  for  delivery.  The 
decision  tool  could  be  incorporated  as  a  "How  Much?"  command 
available  to  compare  possible  choices  in  terms  of 
information  dollar  costs.  Not  all  of  the  options  need  be 
physically  connected  to  the  LAN.  Telephone  calls  are  a  valid 
substitute    for   letters,    but   may  not    be   directly   available 
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through  the  system.  As  long  as  their  prices  appear  in  the 
decision  tool  models,  and  they  are  listed  as  alternates  on 
the  appropriate  function  (Input,  Output,  Send,  Analyze) 
menu,  services  like  the  telephone  and  the  stand  alone 
microcomputer  will  be  included  in  information  marketplace, 
and  therefore  subject  to  the  management  controls  of  the  IRM 
architecture . 

Again,  if  the  information  decision  tool  is  available 
through  the  LAN,  its  use  can  be  recorded  as  measure  of 
information  awareness.  If  the  LAN  can  access  the  separate 
communications  and  information  subsystems  to  connect  users, 
it  can  also  access  those  subsystems  to  get  current  pricing 
and  usage  statistics  for  incorporation  in  the  information 
decision    tool    models. 

The  function  menus  insure  that  the  user  is  reminded 
of  the  possible  substitution  alternatives  at  the  time  the 
choice  is  made.  The  decision  tool  insures  that  the  best 
possible  cost  information  is  available  to  support  the 
choice.  Satisfying  these  requirements  at  the  District  LAN 
interface  insures  the  choice  is  among  all  the  options  and 
all  the  information  services  available  to  the  user's 
purpose,  within  the  whole  architecture,  as  opposed  to  only 
those  choices  available  within  a  given  information 
subsystem. 
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5.   Standard  User  Interface 

Although  not  listed  as  a  management  control  require- 
ment, the  idea  of  a  standard  interface  between  the  IRM 
architecture  and  the  user  is  another  physical  way  to 
strengthen  the  user's  perception  of  the  architecture  as  a 
unified  system,  as  opposed  to  a  collection  of  systems.  It 
could  easily  be  implemented  in  the  proposed  LAN  environment 
by  using  a  standardized  interface  in  the  programs  designed 
to    satisfy    the    control    requirements. 

A  hidden  advantage  to  this  approach  is  that  it 
minimizes  expense;  once  the  interface  is  designed,  the  same 
specifications  are  used  for  each  subsequent  program.  Only 
the  information  presented  on  the  screen  changes;  the 
location  of  status  information  and  instructions,  the  type  of 
selection  (e.g.  by  letter,  from  a  menu),  and  all  the  other 
presentation  characteristics  are  identical.  It  also  shortens 
the  user  learning  time.  A  user  recognizes  the  format  and 
can  instantly  transfer  experience  with  the  interface  he  or 
she    gained   using    other    programs. 

D.       A    VIRTUAL    LAN 

A  variety  of  networks  are  available  to  connect  computers 
and  communications  devices,  each  with  a  variety  of 
characteristics,  and  each  calling  itself  a  Local  Area 
Network.  Active  or  passive,  broadband  or  baseband,  central 
or     distributed     control,      the     list     of     options     is     almost 
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endless.  Network  technology  is  not  fully  developed  yet,  as 
the  C  Support  Plan  recognized  in  deciding  not  to  include  it 
in  the  near-term  budgets.  The  Local  Area  Network  we  have 
examined  to  support  the  integration  and  management  control 
goals  of  the  Coast  Guard  IRM  Architecture  is  not  a  specific 
product.  The  phrase  is  intended  to  describe  an  ability  to 
electronically  cross -connect  the  users,  computers  and 
communications  resources  of  a  Coast  Guard  District  Office  in 
a  productive  way.  This  virtual  LAN  should  provide  reasonably 
guaranteed  delivery  of  information  between  any  pair  of 
nodes,  notification  of  non-delivery,  and  an  auditable  record 
of    access    and    use    of    its    services. 

This  limited  functionality  is  an  adequate  base  from 
which  to  develop  prototype  systems  or  programs  to  satisfy 
the  specified  management  control  requirements,  and  is 
available  at  less  technological  risk  than  that  a  'real'  LAN 
represents.  Shared  logic  word  processors,  such  as  WANG  OIS- 
140's  provide  electronic  mail  and  hardware  terminal 
identifiers;  they  have  been  connected  to  the  record 
telecommunications  system  in  the  First  and  the  Fifth  Coast 
Guard  Districts.  The  Eighth  and  the  Seventeenth  Coast  Guard 
Districts  are  currently  running  Office  Au toma tion / Wor d 
Processing  evaluations  on  Vax  11/780  computer  based  systems; 
these  also  support  electronic  mail,  and  have  resource  usage 
monitor  programs  available.  The  District  minicomputers 
scheduled    for    FY    86    purchase    and    installation      could    provide 
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this  virtual  LAN  function  through  their  installed  terminals 
and  the  appropriate  programming.  Any  of  these  systems  with 
a  sufficiently  large  base  of  connected  users  could  provide 
an  adequate  functional  base  on  which  to  prototype  a  system 
or  program  intended  to  meet  one  or  more  of  the  management 
control  requirements  of  the  IRM  architecture. 

E.   SUMMARY 

We  have  presented  the  reasons  that  the  Coast  Guard 
District  Office  is  the  crucial  level'  within  the  IRM 
architecture  at  which  to  address  the  solution  to  management 
control  requirements  of  that  architecture.  The  power  of  a 
Local  Area  Network  to  physically  reinforce  the  logical 
integration  crucial  to  the  IRM  architecture  and  to  the 
success  of  its  management  controls,  was  presented  and 
examined  for  each  of  the  management  control  requirements 
proposed  in  Chapter  IV.  Finally,  a  distinction  was  drawn 
between  any  specific  technology  or  product  and  the  virtual 
LAN  functionality  required  to  begin  satisfying  the 
requirements . 
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VI.       CONCLUSION 

This  thesis  has  attempted  to  present  a  positive 
description  of  the  integrative  power  of  management  control, 
in  the  setting  of  a  large  information  system.  We  have 
suggested  that,  properly  developed,  the  management  control 
structure  can  unify  diverse  information  systems  into  a 
single  architecture,  and  yet  preserve  a  powerful,  if  subtle, 
ability  to  influence  user  choices.  If  developed  early,  the 
control  structure  can  ease  the  necessary  transitions  of 
maturing   information    systems. 

The  management  control  requirements  proposed  assume  that 
the  intention  of  the  Office  of  C  as  program  managers  for 
the  IRM  architecture  is  to  integrate  the  separate  vertical 
information  subsystems  into  a  cohesive  whole.  The  proposed 
LAN  implementation  of  a  system  to  satisfy  the  control 
requirements  centers  on  accomplishing  that  purpose.  Both  the 
requirements  and  the  LAN  implementation  should  be  evaluated 
with  this  underlying  assumption  of  integrating  the 
architecture  in  mind.  Both  would  have  to  be  modified  to 
support    a   different    concept    of    the    architecture. 

This  early  delineation  of  a  management  control  schema 
for  the  IRM  architecture  may  have  some  practical 
significance  for  the  U.  S.  Coast  Guard.  With  major  hardware 
and    software    procurements    for    the    IRM    architecture    still 
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pending,  the  opportunity  exists  now  to  buy  the  features  or 
capabilities  that  will  be  necessary  to  management  control 
later  on.  More  valuable  than  procurement  opportunities  may 
be  the  necessary  lead  time  created  for  careful  prototype 
development  of  the  programs  and  systems  that  the  management 
control    structure    will    require. 

Although  the  Coast  Guard  IRM  architecture  was  used  as  a 
focus  for  development  of  the  suggested  management  control 
structure,  the  requirements  and  implementation  presented 
could  also  be  applied  to  other  information  systems.  The 
organization  served  by  the  information  system  would  need  to 
have  sufficiently  centralized  control  of  information 
services  that  one  single,  or  several  regional  offices,  could 
set  transfer  prices.  The  company  culture  would  have  to 
support  the  notion  of  user  autonomy  within  limits,  and 
decentralized  decision  responsibility.  The  transfer  pricing 
basis  of  the  control  strategy  assumes  as  well  that 
information  services  costs  are  not  allocated  totally  as 
overhead,     but    charged    to    users    to    a    significant    degree. 

Changing  the  information  flows  of  an  entire  agency  must 
change  the  structure,  if  not  the  nature,  of  the  whole 
organization.  Controlling  the  system  which  implements  these 
changing    information    flows    is    a    necessary    step    to    insuring 

* 

that  the  development  process  will  one  of  directed  growth  and 
not  uncontrolled  change.  This  examination  of  management 
control  within   information  systems    is    meant    to    assist    the 
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Coast      Guard      and      other      organizations      in      retaining 
organizational    control    of    these    technology-driven    changes. 
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